Managing a Portfolio of Product Development Projects under Resource Constraints

Managers of product development (PD) project portfolios face difficult decisions in allocating limited resources to minimize project or portfolio delay. Although PD projects are highly iterative (cyclical), almost all of the vast literature on project scheduling assumes that projects are acyclical. This article addresses this gap with a comprehensive analysis of 31 priority rules (PRs) on 18,480 portfolios containing 55,440 iterative projects. We find that the best PRs for iterative project portfolios differ significantly from those for acyclical ones, and that the best PRs at the project level differ from those at the portfolio level. The best PR depends on project and portfolio characteristics such as network density, iteration intensity, resource loading profile, and amount of resource contention. In particular, by amplifying the effects of iteration, high-density networks hold dramatically different implications for iterative projects. Moreover, the best PR also differs depending on whether the objective is to minimize the average delay to all projects or to minimize delay to the overall portfolio. Thus, a project or portfolio manager who uses the same PR on all occasions will exhibit unnecessarily poor performance in most cases. [Submitted: June 10, 2014. Revised: September 3, 2014. Accepted: September 10, 2014.] Subject Areas: Multiproject Scheduling, Portfolio Management, Priority Rules, Product Development, Project Management, and Resource Constraints. ∗The first author is grateful for support from the Neeley Summer Research Award Program from the Neeley School of Business at TCU and a grant from the U.S. Navy, Office of Naval Research (grant no. N0001411-1-0739). The second author acknowledges the financial support of the University Research Board at the American University of Beirut. †Corresponding author. 333 334 Managing a Portfolio of Product Development Projects under Resource Constraints INTRODUCTION Many firms must manage a portfolio of product development (PD) projects that depend upon a common pool of limited resources. Even if the size of this pool is sufficient for the average needs of all of the projects, they will nevertheless contend for specific resources at particular times, causing delays to individual projects and the portfolio. Some of these situations can be foreseen and managed, but the notoriously iterative nature of PD projects (Kline, 1985; Smith & Eppinger, 1997a) fraught with unplanned and undiscovered rework (Cooper, 1993b) exacerbates the situation. Moreover, the novelty and ambiguity of PD projects makes it difficult to specify their activity networks a priori (Pich, Loch, & Meyer, 2002; Anderson & Joglekar, 2005; Lévárdy & Browning, 2009). In this context, PD project managers must often rely on only the most aggregate projections of resource needs. Hence, resource contentions with other projects in the PD portfolio are especially difficult to predict and manage; they often occur as surprises that derail projects from their plans. Moreover, the managers of individual projects, who want their own projects to be on time, may find themselves at odds with the portfolio manager, who wants to advance the overall portfolio. What is optimal for one project may not be best for the portfolio. Research in this area is important for several reasons. First, most existing research on project portfolios focuses on project selection (and sometimes initial resource allocations), but it does not address the ongoing adjudication of resource contentions. Practicing managers need guidance on this aspect. Second, almost all of the research on resource-constrained (single and multiproject) scheduling addresses only acyclical networks of activities; it does not account for the iterative nature of PD projects, which calls for different managerial approaches. Third, the existing work does not clarify the differences between the single-project and multiproject perspectives (e.g., Dilts & Pence, 2006), which can cause tension between project and portfolio managers. Fourth, the practical reality is that most projects do not actually build detailed activity network models (Liberatore & Titus, 1983; Besner & Hobbs, 2008), even though such models are necessary for applying the methods developed by researchers to find optimal or near-optimal solutions. In PD projects—noted for their novelty, ambiguity, and complexity— building such networks correctly with foresight is especially problematic. Thus, PD project and portfolio managers are inhibited from applying entire streams of research because of disconnects with practice. Instead, when faced with resource contention situations, many managers arbitrate locally with simple decision rules based on activity or project attributes such as “Which activity has more slack time?” or “Which activity is holding up the most other critical activities?” However, the effectiveness of these approaches, generally called priority rules (PRs), can vary greatly depending on the characteristics of the project and the portfolio. It would be extremely beneficial to know which rules to use, which to avoid, and when. This article contributes guidance on the efficacy of various PRs in cyclical activity networks, and it does so in terms of project and portfolio characteristics that can be ascertained without resorting to fully detailed models of the networks. We address the following research questions. What are the most effective PRs in iterative PD projects? How do these differ from acyclical projects? How do these Browning and Yassine 335 results compare for two different objectives—minimizing average project delay and overall portfolio delay? How do project and portfolio characteristics—such as frontor back-loading of resources, network density, amount of iteration, and degree of resource contention—affect the results? What are some new PRs based on the characteristics of iterative projects, and how do these fare in comparison to established PRs? No other study has addressed these questions. To do so, we designed a carefully controlled experiment with 18,480 test portfolios (containing 55,440 projects) with deliberately varied amounts of resource contention, resource frontand back-loading, network density, and activity iteration. We solved each of these portfolios with 31 PRs (20 existing and 11 new), and compared the results in terms of two different objective functions; namely, minimizing average project delay and overall portfolio delay. The results are significant, interesting, and useful for researchers and managers. The choice of PR matters greatly, and PRs that work well for acyclical projects do not necessarily work well for PD projects or portfolios. Several widely advocated PRs performed very poorly for PD project portfolios. The choice of best PR depends significantly on project and portfolio characteristics such as network density, iteration intensity, and amount of resource contention. In particular, by amplifying the effects of iteration, high-density networks hold dramatically different implications for iterative projects. Thus, a project or portfolio manager who uses the same PR on all occasions will exhibit unnecessarily poor performance in most cases. Perhaps most importantly for managers, we are able to distill the overall results in a way that provides managerial guidance without requiring a detailed model of each project’s activity network. These results constitute a significant step beyond other published studies that do not address the cyclical nature of PD project networks. BACKGROUND AND LITERATURE REVIEW This article bridges three streams of literature which so far have been fairly disparate: PD project portfolio management, iteration in PD projects, and resourceconstrained multiproject scheduling. This section describes the background of this research as motivated by each of these areas. PD Project Portfolio Management As the operationalization of a business strategy, project portfolio management (PPM) is essential for the success and survival of PD organizations. Cooper, Edgett, and Kleinschmidt (2002) noted four goals in PPM: maximizing portfolio value, balancing the portfolio, aligning the portfolio with strategic business objectives, and allocating resources optimally across the portfolio. Various tools have been proposed to facilitate PPM—including the Boston Consulting Group’s product portfolio matrix, risk-reward diagrams, Bubble diagrams, etc. (Wysocki & McGarry, 2003; Rad & Levin, 2006)—that generally help to visualize the portfolio with respect to multiple criteria. Various project rating and scoring techniques have been developed for PPM (Terwiesch & Ulrich, 2008), as have sophisticated 336 Managing a Portfolio of Product Development Projects under Resource Constraints mathematical programming and optimization techniques such as mixed integer programs (Beaujon, Marin, & McDonald, 2001; Jiao, Zhang, & Wang, 2007), nonlinear integer programs (Dickinson, Thornton, & Graves, 2001; Gutjahr, Katzensteiner, Reiter, Stummer, & Denk, 2010), and dynamic programs (Loch & Kavadias, 2002; Kavadias & Loch, 2003). Cooper et al. (2002) reported that improved product and firm performance can be attributed to certain types of PPM practices and tools—especially an effective stage-gating process that weeds out poor projects and redistributes resources. Shane and Ulrich (2004) found that, out of the technological innovation, PD, and entrepreneurship research published from 1954 to 2003 in Management Science, “product planning and portfolios” comprised the second largest substream—although they noted that this research had “found very little use in practice.” However, the bulk of research on PPM methods has focused at the strategic level—for example, on project selection—rather than at the operational level—for example, on project execution (Pennypacker & Dye, 2002; Hans, Herroelen, Leus, & Wullink, 2007). Even stage gate reviews offer only relatively macrolevel punctuations of projects. When faced with chronic, day-to-day resource contentions among projects within his or her portfolio, a portfolio manager will find little guidance for a prioritization decision from the PPM literature (Engwall & Jerbrant, 2003; Blichfeldt & Eskerod, 2008). Thus, it is important to extend the scholarly PPM literature beyond portfolio planning to include portfolio execution and control at the level of the dynamic, operational decisions about resource allocation that are important to practicing managers (Anderson & Joglekar, 2005). Iteration in PD Projects Doing something novel, ambiguous, and complex with a multi-disciplinary team requires a degree of experimentation (Thomke, 1998) and convergence on a satisfactory solution (Simon, 1996). Thus, PD and innovation processes are inherently iterative (cyclical) (Kline, 1985; Smith & Eppinger, 1997a; Braha & Bar-Yam, 2007). In general, iteration represents the rework of an activity due to deficiencies with its prior results, triggered by the feedback of information discovered later in the project (Loch & Terwiesch, 2005; Lévárdy & Browning, 2009). These deficiencies could be planned (e.g., an activity deliberately defers work, as in “spiral development”) or unplanned (e.g., due to failure to meet requirements, detected errors, or changes in the inputs upon which the work was done). The advent of “concurrent engineering” has only increased the challenges of parallel work, iteration, and resource constraints. Iteration and rework have been established empirically as significant drivers of PD time, cost, and quality (Cooper, 1993a; Osborne, 1993; Sosa, Mihm, & Browning, 2013). Their effective management is required to plan and control project cost, duration, quality, and risk (Browning & Ramasesh, 2007). However, conventional project management (and scheduling) literature and techniques (e.g., Meredith & Mantel, 2012; PMI, 2013) assume that projects are acyclical and do not account for iteration. On the other hand, most models of iteration in PD projects do not account for resource constraints at all, or do so only in a general way (e.g., without accounting for different resource types and dynamic Browning and Yassine 337 requirements from other projects), and deal only with single projects (e.g., Cho & Eppinger, 2005; Joglekar & Ford, 2005; Lee, Ford, & Joglekar, 2008). It is important to extend the scholarly literature on PD project modeling to explore the very real and practical implications of resource limitations on a portfolio of iterative projects (Froehle & Roth, 2007). Resource-Constrained Multiproject Scheduling Resource-constrained multiproject scheduling (RCMPS) seeks to optimize the performance of a set of projects that draw on a common pool of resources (e.g., Pritsker, Watters, & Wolfe, 1969; Hans et al., 2007; Hartmann & Briskorn, 2009). Solutions are found by scheduling the activities in each project and determining the projects’ resulting durations. Whenever the resource needs of concurrent activities exceed the amount available, a decision must be made to prioritize some activities and delay others. The RCMPS problem is strongly NP-hard (Lenstra & Kan, 1978), so exact solution methods are impractical for large problems (Herroelen, 2005). Research has thus focused on heuristic procedures (Kolisch & Hartmann, 1999, 2005), including PRs (e.g., Browning & Yassine, 2010b; Vázquez, Calvo, & Ordóñez, 2015), classical meta-heuristics (e.g., Bouleimen & Lecocq, 2000; Linyi & Yan, 2007; Gonçalves, Mendes, & Resende, 2008; Okada, Lin, & Gen, 2009), nonstandard meta-heuristics (e.g., Confessore, Giordani, & Rismondo, 2007; Homberger, 2007), and other heuristics (e.g., Lova & Tormos, 2002). PRs include singleand multipass methods (Hartmann & Kolisch, 2000), where single-pass PRs draw upon a single value (such as start time or duration) and multipass methods either employ more than one PR in succession (e.g., Lova & Tormos, 2001) or combine a single PR with some degree of randomness. PRs can also be classified according to whether they use activity-, project-, or resource-related information (Kolisch, 1996a), although some multipass PRs draw upon more than one of these (Hartmann & Kolisch, 2000). Although much of the recent research on RCMPS has emphasized meta-heuristics, PRs remain important for several reasons: PRs’ lesser computational expense makes them attractive for very large problems (Kolisch, 1996a), which are common in RCMPS (as compared to single-project cases). PRs are a component of other (local search-based and sampling) heuristics (Kolisch, 1996b). PRs provide initial solutions for meta-heuristics (Hartmann & Kolisch, 2000). PRs are used extensively by commercial project scheduling software (Herroelen, 2005) and practitioners. PRs can be gainfully employed by managers even without the formal activity network models required for the application of meta-heuristics (Browning & Yassine, 2010b). The last reason is especially compelling, because it does not matter how large a problem a modern computer can optimally process, nor how fast a meta-heuristic can reach a near-optimal solution, nor how good that solution is, if a project does not have the requisite input—an accurate activity network model (which is actually 338 Managing a Portfolio of Product Development Projects under Resource Constraints quite rare for PD projects). When faced with a resource allocation decision, a practicing project manager will often make a quick call based on intuition or a simple rule of thumb. Therefore, a litany of PRs remain prominent in contemporary project management textbooks (e.g., Meredith & Mantel, 2012). However, almost all RCMPS studies, whether using PRs or other heuristics or meta-heuristics, have addressed only acyclical networks, so their guidance could mislead managers of iterative PD projects and portfolios. Only a few RCMPS papers have looked at cyclical projects. Tukel (1996) investigated the performance of five PRs and confirmed that feedback in an activity network (i.e., cycles) affected PR performance. Luh, Liu, and Moser (1999) studied the problem of scheduling design activities with an uncertain number of iterations by using a stochastic dynamic programming approach to determine the optimal start times of activities to minimize expected weighted tardiness. Similarly, Yan, Wang, and Jiang (2002) presented a branch-and-bound algorithm to determine an optimal project schedule in the presence of uncertain activity iterations. Zhuang and Yassine (2004) developed a genetic algorithm-based approach for solving the iterative RCPSP that randomly generates a value based on the feedback probability and thus decides whether to incorporate the feedback into the schedule or not. Yet, none of these works address a portfolio of PD projects, nor do they provide guidance on PR performance in diverse situations. Moreover, each requires a complete and accurate model of the activity network, something that is unlikely to exist for many PD projects. Thus, it is important to extend the scholarly literature on RCMPS to account for the realistic context of iterative PD projects. RESEARCH METHODS To investigate the performance of popular and high-potential PRs, we designed a suite of test portfolios with a distribution of PD project and portfolio characteristics and solved these for two objective functions with 31 PRs. This section describes the project and portfolio characteristics and their measures, the test portfolios, the PRs, the objective functions, and the solution procedure. PD Project and Portfolio Characteristics and Measures PD projects can differ substantially in terms of their network density, iteration intensity, and resource loading profile. Portfolios can vary in terms of the characteristics of their constituent projects and the overall amount of resource contention among them. These characteristics must be considered because the literature reports that they have a significant effect on PR performance. Network density Several studies (e.g., Davis & Patterson, 1975; Ulusoy & Özdamar, 1989) in the RCMPS literature have established the significance of network complexity—the density of precedence constraints—to PR performance. Low-density networks are less precedence-constrained, which provides more degrees of freedom in determining a solution and therefore makes them more difficult to solve. Highdensity networks contain many more precedence relationships among the activities, Browning and Yassine 339 implying fewer alternatives for starting activities sooner or later without delaying the project. Hence, PR performance differences increase with decreasing network density. Furthermore, not all precedence relationships (often called arcs in the RCMPS literature) are equally important (Tavares, Ferreira, & Coelho, 2002; Nassar & Hegab, 2006). For example, if three activities are related by two arcs in a serial fashion, then a third arc going from the first to the third adds no further constraint to the network. This latter arc is thus called a redundant arc. The more recent density measures in the literature focus on nonredundant arcs. We adopt Browning and Yassine’s (2010a) project network density measure: C = 4A ′ − 4N + 4 (N − 2) , (1) where A′ is the number of nonredundant, feed-forward arcs, N is the number of nodes (activities), and C is normalized over [0, 1]. For example, 30 nonredundant, feed-forward arcs among 20 activities implies a fairly sparse network with C = 0.14, whereas 75 such arcs among 20 activities yields C = 0.69. Although the definitions and measures of network density from the RCMPS literature assume an acyclical network and therefore ignore any feedback arcs, C still provides a useful indicator in our context of iterative PD projects. Figure 1 shows an example portfolio with three projects, each with 20 activities shown in both Gantt chart and design structure matrix (DSM) representations (Eppinger & Browning, 2012). In each Gantt chart, the activities appear in rows as a bar with width proportional to their duration. The horizontal axis is a time line showing the earliest start and finish time of each activity (ignoring any iteration or resource limitations). In each DSM, the activities are listed along the diagonal, and an arc from activity i to j is noted by an entry in cell (j, i) (row j, column i). For example, in project (a), activity 1 is a predecessor to activities 2–10. Feedforward arcs appear as subdiagonal marks in the DSMs; super-diagonal marks represent feedback arcs (to be discussed later). Project (a) has 75 nonredundant, feed-forward arcs, and projects (b) and (c) each have 30. The maximum possible number of feed-forward arcs is (N2 – N)/2, which is 190 when N = 20, as can be seen by the number of cells available below the diagonal in each DSM. The maximum possible number of nonredundant, feed-forward arcs when N = 20 is 100, as determined by Equation (1), although the actual number possible in any particular project may be less than this upper bound depending on the activity network’s tiering structure (Browning & Yassine, 2010a), which is shown by the empty blocks along the diagonal in each DSM. For example, in Figure 1 projects (a) and (c) each have four tiers, while project (b) has three. (These tiers are also discernible in the Gantt charts.) Any subdiagonal marks within the blocks along the diagonal would increase the number of tiers. Any subdiagonal marks outside the further dashed line blocks would be redundant because they would bypass an intermediate tier. For example, in project (a) a mark in cell (20, 1) would be redundant because it would imply a dependency of activity 20 (in tier 4) on activity 1 (in tier 1), even though this dependency already exists indirectly via other activities (e.g., 10 and 17) in tiers 2 and 3. 340 Managing a Portfolio of Product Development Projects under Resource Constraints F ig ur e 1: E xa m pl e po rt fo lio of th re e pr oj ec ts ,e ac h sh ow n w ith G an tt ch ar ta nd D SM re pr es en ta tio ns . (a ) C = 0. 69 (b ) C = 0. 14 (c ) C = 0. 14 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20